Explanations of the Patent Claims 



Claims 31, 33, 34, 37-43 and Claim 53 are cancelled. 

Claims 28-30, 32, 35, 36 and 44-52 are amended and reasons given. 

In the claims, insertions are underlined words and deletions are in bold typeface within 
square brackets [ ]. 

The following explanations clarify the novelty, inventive steps and industrial 
applicability of this invention and claims. To avoid confusion in terminology such as 
"Data Identification Number", "Index Number", "PIN", "Card Identification Number" 
and "Account Number", here are the definitions of terms used in my application and the 
explanation: 

Each Multi- Application Card (MAC) has a number. This is referred to in the claim as a 
"data identification number" and in explanations as a "MAC identification number". 
The MAC identification number is read from the MAC by a card reader device. 

Each MAC corresponds to a record in a database. Each record in the database (whose 
key is the MAC Identification Number) contains sub-records; each sub-record is 
locatable by the MAC identification number and an Index Number, also referred to as a 
Card Identification Number (CIN). The Index Number, typically a 4-digit number, is 
physically entered at a data entry device such as a keypad. 

Most credit and debit card users are familiar with the use of a Person al Identification 
Number (PIN), which has served to identify the owner of a debit card. A PIN is also 
typically a 4-digit number, physically entered at a data entry device such as a keypad. 

NOTE: Card industry research found that OVER 90% OF CARD OWNERS USE 
THE SAME PIN FOR AjLL THEIR DEBIT, CHECK, ATM AND CONVENIENCE 
CARDS. This is logical because a PIN identifies the person, not the card. CREDIT 
CARDS ARE SIGNATURE-VERIFIED AND DO NOT USE PINS. 

In my invention, each sub-record within the group referred to (in claims 28 and 50) as a 
"first subset" of index numbers identifies (or contains, or points to) a single account 
number. The accoimt number could be a credit card number, a debit card number, 
driver's license number, etc. Each sub-record within the group referred to (in claims 29 
and 5 1) as the "second subset" of index numbers contains (or points to) a Lock code 
instead of an account number. Each sub-record within the group referred to (in claims 30 
and 52) as the "third subset" of index numbers contains (or points to) an Unlock code, 
instead of an account number or a Lock code. 

Here are the steps involved in using my invention: 

1 . The multi-application card (MAC) is read at a card reader. The card reader reads 
the MAC identification number. 
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2. As when using a debit card, the user is asked to physically enter a number in the 
keypad. The user manually enters a number (called an Index Number or Card 
Identification Number), typically a 4-digit number. 

3. The MAC Number and the Index Number are sent from the point-of-service to the 
card translator system. Using the MAC number, the translator locates a record in its 
database. The index number (or Card Identification Number) is used to find a sub- 
record (or entry) within the record. If, as the claim reads, the index number is within 
the first subset of index numbers (i.e. the sub-record identifies or contains an account 
number), that account number is retrieved and processing continues. The account 
number could be a credit card number, a debit card number or some other account 
number. If the index number is within the second subset of index numbers (i.e. the 
sub-record identifies or contains a Lock code instead of an account number), the 
entire record is flagged as "locked" or "disabled". The MAC can no longer be used 
to access an account number from the database until the lock flag is removed. If the 
index number is within the third subset of index numbers (i.e. the sub-record 
identifies or contains an Unlock code instead of an account number or Lock code), 
the Lock flag for the record is removed, effectively "imlocking" or "re-enabling" the 
MAC. 



Re: US Patent 5,770,843 (ROSE et al.): 

In contrast to my invention, here's how the ROSE system works: 

1 . The multi-application card (MAC) is swiped at a card reader. The card reader 
reads the MAC identification number. That's where the similarity ends. 

2. The MAC number is sent to the remote system. It reads the record, searches all the 
sub-records (or entries) for accoimt numbers in the record and displays ALL accounts 
on a screen for the user to select one. 

3. With all accounts on the MAC displayed - before having to enter anything - the 
user chooses one of the accounts, e.g. a Bank of America (BofA) Debit card. 

4. The system now asks for the PIN of the BofA Debit card. The user enters the PIN 
for the BofA Debit card at a data entry device. 

5. The PIN is sent to the remote system. If the PIN (which can be the same for ALL 
the accounts) matches that of the BofA Debit card, tiie transaction is allowed to 
proceed. 

Differences between ROSE and the current Invention: 

Here are important differences between my invention and that of ROSE et al.: 

1 . ROSE uses PINs, which (in over 90% of cases) are found to be the same for all 
accounts of a card owner, while my invention uses Index Numbers which must 
be unique for each account, enforcing better security. 



3 



2 ROSE discloses to a potential thief ALL the accounts on a MAC record by merely 
■ swiping the MAC at a point-of-service terminal - even before the user is asked to 

enter anything. As a result, any user (including a thief) could never make a 
mistake in selecting an account - because ALL accounts ^Y^o^.^p n^^^' 
selects from among them. If there are 5 accounts on the MAC, in the ROSE 
invention, only 5 accounts are displayed and the user has 5 possible choices^ In 
my invention (assuming 4 digits are used for the I'jf *ere ^e 1 ^ 

Dossible numbers (0000 to 9999) that the user could enter. Of the 10,000 possible 
numbers, typically more than 99.9% would be incorrect. Only the owner would 
know what accounts are on the MAC and the unique Index Number pertaimng to 

3 ^ifc^d^ do not use PINs. In the ROSE system, if the MAC database uses the 
same PIN as the card issuer, a thief with a Multi-Application Card could simply 
swipe the MAC and select a credit card - which has no PIN - to use it. 

4 Let us assume the ROSE invention forces a PIN on all cards including credit 
cards Again, the thief sees all the accounts on the MAC by merely swiping the 
MAC at a point-of-sale terminal. If the thief knows the PIN of any one card 
belonging to the MAC owner, inherent in the design and confirmed by industry 
statistics, the thief could almost certainly use all the accounts on the MAC^ 
Ironically the ROSE invention would help a thief by displaying all the card 
accounts on the MAC, by simply swiping it at a point of sale. My mvention^ 
requires the user to enter the index/CIN of a valid card account withm displaying 
what accounts are on the MAC. Even if the MAC owner uses the PIN of a as 
its index/CIN, a thief with one PIN could access only one account on the MAL.^ 

5 The ROSE invention requires multiple exchanges of messages between the card 
■ reader and the database to identify a specific account number. By using unique 

mdex numbers for each stored account, my invention requires just one exchange 
of messages to identify a specific account number. This is extremely important 
because even milliseconds matter when it comes to card authorization 

6 The ROSE invention was designed for a kiosk; it requires a device that cj 
display all accounts on the record so that a user can select from among them. My 
fnvSon does not require such a device; it can use a standard debit card keypad. 

7 Changes in account numbers (whether in ROSE or my invention) would require a 
change to bol^bases - the card issuer database and the MAC database. 
H^lver in the ROSE invention - unless the MAC uses a different PIN from that 
fn t^e ca^^d issuer database - a change in the PIN of any account wodd reqm^^^^ 
chLge in the database of the card issuer and also a change to the PIN m the MAC 
database In my invention, changes to CINs and PINs are independent of each 
oto If the M^C owner changes the index number (or CIN) of an account no 
ck^ge s required to the issuer database. If the MAC owner changes the PIN of a 
carTthe only database needing the change is the issuer database. Since the MAC 
d'ablse in my invention does not use account PINs, no change is required o it. 

8 In the ROSE invention, it is NOT possible to identify m accoun number 
usinfi the MAC Identification Number and the PIN because mu t.ple 
Tou^s have the same PIN. In ROSE, the PIN is used to -erdy ^/irm a 
previously-selected (and already identified) account number. In my 
fnvltion^the two data items, i.e. the MAC Identification Number and the 
Index, are sufficient to identify an individual account number. 

9 beSve use of the words "identify" and "single account number" m my claims 
dr^rentiates this invention from ROSE. TTieCo^^^^ 



European Patent Office (Euro. Pat. EP 1221 144) acknowledges the difference and 
so does the Canadian Intellectual Property Ofifice. The USPTO Examiner of this 
application also acknowledges the difference and is seeking rewording of the 
claims to reflect the difference. Therefore, as in my Canadian patent application 
(CA 2,381,807, for which I now have a Notice of Allowance on 21 claims), I have 
amended my claims to state that the data identification number and the index 
number identify "a single account number", clearly different from the teachings of 
ROSE and PIERCE. The phrase "chosen by an/the authorized holder of the card 
device" has been deleted from claims 28-30 and 50-52. I trust these amendments 
meet with your approval. 



Differences between PIERCE and the current Invention: 

Here are important differences between my invention and that of PIERCE: 

1 . PIERCE describes a system that re-directs data from the retailer subsystem to the 
appropriate card issuer subsystem. The use of a card translator subsystem to 
translate (without additional input) an identification number and index 
number to a single account number is not in the teachings of either PIERCE 
or ROSE. 

2. The claims in this patent application point out, as shown in Figure 6 of the 
drawings, that a card translator (a subsystem to convert an identification number 
and index number to a single account number) may be located in, or connected to, 
a client/retailer subsystem, an issuer subsystem or an intermediate subsystem 
usually referred to in the industry as a card processor. 

3. As stated earlier, I believe using the words "identify" and "single account 
number" in my claims differentiates this invention from ROSE and PIERCE. I 
have amended my claims to state that the data identification number and the index 
number identify a single account number, clearly different from the teachings of 
ROSE and PIERCE. The phrase "chosen by an/the authorized holder of the card 
device" has been deleted from claims 28-30 and 50-52. I trust these amendments 
meet with your approval. 
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